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ABSTRACT 


In  this  thesis,  we  discuss  the  development  of  the  neces¬ 
sary  tools  for  the  performance  evaluation  of  a  multi-backend 
database  system,  kncwn  as  MDBS.  The  basic  motivation  of  the 
mutlti- backend  database  system  (MDBS)  is  to  develop  an 
architecture  which  spreads  the  work  of  the  database  system 
among  multiple  backends.  It  is  a  major  aim  of  this  system 
to  allow  capacity  growth  by  the  use  of  additional  disk 
drives  and  performance  improvement  by  the  use  of  additional 
backends.  However,  to  verify  the  design  and  implementation, 
it  is  necessary  to  test  the  capability  of  MDBS  in  capacity 
growth  and  performance  gain. 

Three  tools  for  the  performance  and  capacity  tests  are 
investigated.  The  first  tool  is  the  file  generation  package 
which  creates  test  f.  les  for  .  artificial  database.  The 
second  tool  is  the  database  load  subsystem  which  loads  the 
artificial  database  into  MDBS.  The  third  tool  is  the 
reguest  generation  package.  This  package  creates  test 
requests  to  query  MDBS. 

The  following  methodology  is  used  to  create  an  effective 
tool.  First,  the  properties  of  an  ideal  tool  are  described. 
Then  available  existing  programs  are  reviewed  and  evaluated 
to  determine  which  program  best  meets  the  desired  features. 
Lastly,  the  programs  are  upgraded  to  ensure  that  they  are 
compatible  with  the  current  implementation,  and  meet  the 
desired  features. 

The  sain  goal  is  to  develop  the  necessary  tools  to 
generate  tests  in  measuring  the  extensibility  of  MDBS,  i.e. , 
how  does  MDBS  perform  as  more  backends  are  added? 
Performance  is  expected  to  improve  (maintain)  as  the  number 
(size)  of  the  backends  (database)  is  increased. 
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This  chapter  presents  a  brief  review  of  the  multi - 
backend  database  system  (MDBS) «  First,  the  physical 

arrangement  of  MDBS  is  presented.  This  is  followed  by  a 

presentation  of  the  process  structure  of  MDBS.  Lastly,  the 
actions  taken  in  servicing  requests,  both  insert  and  non¬ 
insert  requests,  are  reviewed.  References  are  cited  for  the 
interested  reader  in  order  to  gain  a  more  detailed  under¬ 
standing  of  MDBS. 

A.  THE  HOLTI-BACKEBD  DATABASE  SYSTEM 

The  multi- tackend  database  system  (MDBS)  uses  one  li- 
coaputer  as  the  master  or  controller,  and  a  varying  n  ner 
of  minicomputers  and  their  disks  as  slaves  or  back  J~. 
MDBS  is  designed  to  provide  database  growth  and  perform  ce 
enhancement  by  the  addition  cf  identical  backends.  No 
special  hardware  is  required.  The  backends  are  configured 
in  a  parallel  fashion.  A  new  hackend  may  be  added  by  simply 
replicating  the  existing  software  on  the  new  backend,  thus 
avoiding  reprogramming  efforts.  A  prototype  MDBS  has  been 
completed  in  order  to  carry  out  the  design  verification  and 
performance  evaluation  developed  in  [Ref.  1]  and  [Ref.  2]. 
The  implementation  efforts  are  described  in  [Ref.  3]  through 
[Ref.  5]. 

The  equipment  configuration  of  the  system  is  shown  in 
Pigure  1.1.  The  host  computer  is  connected  to  MDBS  through 
the  controller.  The  backends  are  connected  to  the 
controller  through  a  broadcast  bus.  When  the  controller 
receives  a  request  frcm  the  host,  it  delivers  the  request 
to  all  backends  simultaneously  over  the  broadcast  bus. 


Piquce  1.1  HARDH  ABE  CONFIGURATION  OP  BOBS. 


Since  the  data  is  distributed  across  all  backends,  all  back- 
ends  can  execute  a  request  in  parallel. 

The  division  cf  labor  between  the  controller  and  the 
backends  is  illustrated  through  the  process  structure  of 
Figure  1.2.  The  HOBS  controller  handles  three  functions. 
The  re  guest  preparation  function  prepares  a  request  for 
transmission  to  the  backends.  The  insert  information  gener¬ 
ation  function  processes  the  insert  requests  which  require 
additional  information  used  by  the  backends.  The  post 
processing  function  handles  the  work  necessary  when  the 
replies  are  returned  to  the  controller  from  the  backends  but 
before  reaching  the  host. 

The  backends  in  MDBS  carry  out  three  different  func¬ 
tions.  The  directory  management  function  performs 
descriptor  search,  cluster  search,  address  generation,  and 
directory  table  maintenance.  The  record  processing  function 
performs  record  storage,  record  retrieval,  record  selection, 
and  at  tribute- value  extraction  of  the  retrieved  records. 
The  concurrency  control  function  performs  operations  to 
ensure  that  the  concurrent  and  interleaved  execution  of  the 
user  requests  will  keep  the  database  consistent. 

Before  proceeding  to  describe  the  sequence  of  actions 
required  during  a  request  servicing,  some  terminology  is 
presented  as  a  review.  The  smallest  unit  of  data  is  a 
keyword,  which  is  an  attribute-value  pair.  Information  is 
stored  in  terms  of  records,  which  are  made  up  of  keywords 
and  a  record  body.  h  predicate  is  of  the  form  (attribute, 
relational  operator,  value).  A  query  is  any  Boolean  expres¬ 
sion  of  predicates.  Records  are  logically  grouped  into 
clusters  based  on  the  attribute  values  and  the  attribute- 
value  ranges  in  the  records.  Internally,  the  values  and 
value  ranges  are  called  descriptors.  For  the  user,  these 
attribute  values  are  termed  keywords.  Each  descriptor  is 
identified  by  a  descriptor  id  to  save  computing  time  and 
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memory  space.  A  prespecified  set  of  requests  is  referred  to 
as  a  transaction. 

B.  BBQOEST  BXSCUTId 

This  section  describes  the  sequence  of  actions  taken  by 
MDBS  in  carrying  oat  a  request.  First,  the  insert  request 
vill  be  discussed.  Then  the  non-insert  requests  will  be 
described.  Non-insert  requests  are  requests  for  deletion, 
retrieval,  or  update. 

1.  Actions  for  insert  Bequests 

The  sequence  of  actions  for  an  insert  request  is 
shown  in  Figure  1.3.  A  request  from  the  host  machine  enters 
the  Bequest  Preparation  process.  Request  Preparation  broad¬ 
casts  the  number  of  requests  in  the  transaction  to  Post 
processing  in  order  to  determine  when  a  transaction  is 
completed.  Request  Preparation  may  send  an  error  to  Post 
Processing  if  there  is  a  syntax  error  in  the  request.  when 
a  transaction  is  completed  Post  Processing  sends  the  results 
to  the  host  machine.  Request  Preparation  then  broadcasts 
the  request  to  Directory  Management.  Each  backend  finds  the 
descriptor  ids  associated  with  the  request.  The  backends 
then  exchange  descriptor  id  information. 

After  receiving  the  descriptor  ids  from  the  other 
backends.  Directory  Management  sends  the  cluster  id  to 
Insert  Information  Generation.  Insert  Information 

Generation  then  determines  which  backend  is  to  store  the 
record.  The  selected  backend  determines  the  address  of  the 
new  record  and  stores  it.  The  other  backends  discard  the 
record.  Finally,  Record  Processing  sends  an  action- 
completed  message  to  Post  Processing,  which  in  turn  informs 
the  host. 


I 

I 


Figure  1.3  SEQUENCE  OF  ACTIONS  FOR  AN  INSERT  REQUEST. 


15 


2.  Asiiaas  I21  EsaaesU 


The  sequence  of  actions  foe  a  non-insert  request  is 
shewn  in  Figure  1.4.  The  actions  for  a  retriawe  will  be 
discussed  only,  since  the  other  types  cf  requests  are  quite 
siailar.  A  request  froa  the  host  aachine  enters  the  Bequest 
Preparation  process.  Bequest  Preparation  sends  the  number 
of  requests  in  the  transaction  tc  Post  Processing  in  order 
to  det arsine  when  a  transaction  is  coapleted.  Request 
Preparation  aay  send  an  error  to  Post  Processing  if  there  is 
a  syntax  error  in  the  request.  Rhen  a  transaction  is 
coapleted.  Post  Processing  sends  the  results  to  the  host 
aachine.  Request  Preparation  then  broadcasts  the  request  to 
Directory  aanageaent.  Each  backend  finds  the  descriptor  ids 
associated  with  the  request.  The  backends  then  exchange 
descriptor  id  inforaation. 

After  receiving  the  descriptor  ids  froa  the  other 
backends.  Directory  Hanageaent  determines  the  cluster  ids. 
Lastly,  Directory  Hanageaent  determines  the  addresses  of  the 
records  of  the  identified  clusters.  Record  Processing  gets 
the  records  from  secondary  storage  and  extracts  the  neces¬ 
sary  inforaation.  If  aggregate  operators,  for  example,  the 
average,  are  specified  in  the  retrieve  request,  they  are 
applied  at  this  tine.  The  partially  aggregated  values  are 
sent  to  Pest  Processing.  Post  Processing  sends  the  results 
to  the  host  following  any  further  aggregate  operations. 

This  concludes  the  review  of  HDBS.  Attention  is  now 
turned  toward  perforaance  issues  of  this  system  in  the 
following  chapter. 
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Figure  1.4  SEQUENCE  OF  ACTIONS  FOB  A  NON-INS  EBT  BEQUEST 


II.  iS££mi££  gVALDATIQB 


A.  TWO  VIEWS  OE  PEBFOBHAHCE  MEASUREMENT 

Now  that  the  MEBS  has  been  described,  it  is  reasonable 
to  ask  "how  does  one  determine  the  performance  of  such  a 
system?"  There  are  two  viewpoints  of  performance  evalua¬ 
tion.  The  first  is  the  macroscopic  viewpoint  in  which  the 
key  performance  measurement  is  the  relative  response  time. 
The  second  viewpoint  is  the  microscopic  viewpoint.  This 
viewpoint  is  concerned  with  measuring  the  times  needed  to 
perform  various  subtasks  which  are  carried  out  in  servicing 
a  request.  In  (B«f.  6],  the  motivation  for  the  macroscopic 
measurement  is  provided.  This  chapter  is  concerned  with 
describing  the  performance  issues  which  arise  when  using  the 
macroscopic  viewpoint.  Thus  in  testing  the  MDBS,  the  macro¬ 
scopic  viewpoint  will  be  used  before  proceeding  to  the 
microscopic  viewpoint. 

B.  CBITBBIA  FOB  PERFORMANCE  EVALD ATI  ON  AND  TOOL  SELECTION 

As  stated  above,  with  the  macroscopic  viewpoint  the 
key  performance  measurement  is  the  relative  response  time. 
That  is,  the  concern  lies  mainly  with  the  affect  of  various 
changes  to  the  system  on  the  response  time.  These  changes 
and  therefore  their  relative  response  times  are  prompted  by 
the  variables  described  in  the  following  section. 
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2.  ESrfSIHBSi  JSSU5 


The  macroscopic  viewpoint  is  concerned  with  changiag 
four  categories  of  variables  and  observing  their  affect  on 
the  relative  response  tiae.  These  variables  include  systen 
configuration  variables,  cluster  formation  variables, 
request  construction  variables,  and  storage  variables. 

The  system  configuration  variables  deal  with  the 
following  guesticns  on  how  MDBS  perforns  when:  the  number 
of  backends  resains  constant  but  the  database  increases,  the 
database  reaains  constant  and  the  number  of  backends 
increases,  the  number  of  concurrent  users  increases,  the 
number  of  requests  per  transaction  increases,  and  the  pres¬ 
ence  of  concurrency  ccntrol  is  measured  against  the  absence 
of  concurrency  control. 

The  cluster  formation  variables  deal  with  the 
following  questions  on  how  MDBS  performs  when:  the  number 
of  descriptors  on  any  attribute  increases,  the  average  size 
of  clusters  in  the  database  ranges  over  small,  medium,  and 
large  size,  and  the  number  of  attributes  and  thus  the  size 
of  the  attribute  table  increases. 

The  request  construction  variables  deal  with  the 
following  guesticns  on  how  HDBS  performs  when:  the  request 
makeup  is  retrieve- intensive  vs.  update-intensive,  the 
complexity  of  the  query  increases,  the  relative  mix  of  query 
types  is  varied,  the  retrieved  information  is  either  a 
projection  of  the  record  or  the  whole  record,  the  query 
predicates  are  permuted,  and  the  request  uses  either  non- 
directory  keywords  or  directory  keywords. 

Lastly,  the  storage  variables  deal  with  the 
following  questions  on  how  HDES  performs  when:  the  data 
placement  strategy  of  the  database  changes,  the  tuple  width 
increases,  and  the  size  of  the  retrieved  information  exceeds 
that  available  in  the  main  memory. 
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Thus  it  can  b€  seen  that  several  variables  influence 
the  performance  of  BDES.  This  is  not  an  all-inclusive  list. 
However,  the  list  will  serve  as  a  basis  for  developing  the 
desired  properties  of  each  performance  tool.  Each  tool  will 
be  discussed  along  with  its  desired  properries  in  the 
following  sections. 

C.  DBS  IB  ABLE  PBOPEHTIES  OF  THE  TBST  FILE  GEHERATIOB  PACKAGE 

The  purpose  of  the  file  generation  package  is  to  create 
an  artificial  database  which  will  eventually  be  loaded  into 
BDES.  This  is  tbe  first  tool  tc  be  used  for  the  evaluation. 
Several  parameters  are  likely  to  be  varied  in  the  light  of 
the  performance  issues.  Their  desired  properties  are  as 
follows.  The  input  parameters  to  such  a  package  may 
include:  file  size  in  number  cf  records  per  file, 
attribute -value  size  in  bytes  of  storage,  record  size  in 
number  of  attributes  values,  data  types  of  attribute  values, 
and  database  size  in  number  of  files  per  database.  In  addi¬ 
tion,  parameters  must  indicate  whether  values  of  attributes 
are  taken  from  randcm  functions,  or  from  predetermined  sets, 
and  whether  uniqueness  of  values  is  desired. 

D.  DBS IB ABLE  PBOPEHTIES  OF  THE  DATABASE  LOAD  SUBSTSTEfl 

The  database  load  subsystem  is  responsible  for  taking 
the  files  created  by  the  file  generation  package  and  for 
properly  loading  the  files  into  BDBS.  In  the  process  of 
loading  the  database,  the  database  lead  subsystem  must  also 
create  the  necessary  tables  used  in  directory  management. 

The  database  lead  subsystem  must  be  designed  so  that  the 
performance  evaluation  may  utilize  various  cluster  formation 
variables  and  storage  variables  with  minimum  effort.  The 
cluster  formation  variables  and  storage  variables  with  which 
the  performance  may  be  concerned  include  the  following.  The 


performance  may  be  expected  to  depend  upon  whether  the 
number  of  descriptors  (attributes)  is  large  or  small. 
Certainly,  when  entering  a  large  number  of  descriptors 
(attributes)  ,  the  chance  for  error  in  this  menial  task  is 
great.  Therefore,  the  ease  of  specifying  the  descriptors 
(attributes)  must  be  guaranteed.  The  variation  of  cluster 
size  may  affect  performance.  The  cluster  size  is  a  function 
of  the  number  of  descriptors,  the  size  of  the  input  files, 
and  the  values  used  in  the  attribute  fields.  Therefore, 
these  three  parameters  should  be  entered  independently.  The 
data  placement  strategy,  i.e.,  how  records  are  distributed 
across  the  backends,  also  affects  performance.  while  simu¬ 
lation  studies  described  in  [Hef.  1]  and  [Bef.  2]  show  that 
the  track-splitting-with-random-placeaenf  strategy  is  the 
most  desirable,  the  ability  to  change  the  placement  strategy 
will  provide  a  means  cf  confirming  these  studies. 

E.  DBS  IB  ABLE  PBOPIBTIES  OF  TUB  BEQUEST  GBMEBATIOI  PACKAGE 

The  request  generation  package  is  concerned  with 
creating  and  executing  test  requests.  The  request  formation 
variables  will  te  altered  by  the  performance  evaluation  team 
in  this  performance  evaluation  tool.  The  request  formation 
variables  will  be  changed  in  crder  to  vary  the  following: 
the  percentage  of  the  types  of  requests  (retrieve,  update, 
insert,  or  delete),  the  percentage  of  aggregate  operators 
(ave,  max,  min,  sun,  and  count)  in  retrieve  requests,  the 
complexity  of  the  request  query  (A  simple  query  will  consist 
of  one  to  two  predicates,  and  a  complex  query  will  consist 
of  ten  to  fifteen  predicates)  ,  the  order  of  the  predicates 
appearing  in  the  reguest,  and  the  number  of  attributes  to  be 
projected  in  the  retrieve  request. 
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The  request  generation  package  aust  also  possess  the 
ability  to  allow  the  following:  wary  the  length  of  the 
transaction  to  determine  its  effect  on  systee  perforaance, 
tag  requests  with  user  identification  in  order  to  test 
concurrency  control,  retrieval  of  a  record  defined  over  the 
null  descriptor,  execute  a  retrieve  request  where  the  entire 
cluster  is  stored  at  one  backend,  and  coapare  the  above 
perforaance  with  a  retrieve  request  where  the  cluster  is 
distributed  across  all  backends. 

It  is  now  appropriate  to  proceed  to  the  details  of  each 
of  the  above  three  tools.  In  the  following  chapter  the  test 
file  generation  package  is  discussed.  Chapter  IT  deals  with 
the  details  of  the  database  load  subsystem,  and  Chapter  T 
develops  the  test  request  generation  package. 


22 


hi.  313  Isa  fH3  gbebbetioh  3303423 


In  this  chapter,  we  discuss  the  test  file  generation 
package  development.  In  the  first  two  sections,  we  review 
the  purpose  and  desired  properties  of  the  package.  In  the 
next  two  sections,  we  discuss  how  the  basic  program  was 
selected  from  existing  file  generation  tools.  Pinally,  in 
the  last  two  sections  we  discuss  the  upgrading  of  the 
selected  program  and  future  enhancements  which  will  further 
aid  the  performance  evaluation  team. 

km  THE  P DEPOSE 

The  first  set  cf  performance  evaluation  experiments  will 
use  test  data  which  is  generated  by  a  program  in  the  form  as 
specified  by  the  experimenter.  This  process  may  be  viewed 
in  three  steps.  The  first  step  consists  of  defining  the 
structure  cf  the  files  to  be  generated.  The  second  step 
determines  where  the  values  for  the  specified  attributes 
will  be  generated.  Lastly,  the  files  are  generated  and 
stcred  for  future  use. 

B.  DBS IB  ID  PHOPEBTIES 

The  input  parameters  to  such  a  package  may  include: 
file  size  in  number  of  records  per  file,  attribute  size  in 
bytes  of  storage,  record  size  in  number  of  attribute  values, 
data  types  of  attributes,  database  size  in  number  of  files 
per  database,  whether  values  of  attributes  are  taken  from 
random  functions  or  are  selected  from  predetermined  sets, 
and  whether  unigueness  of  values  is  desired. 
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C.  EXIST I BG  PBGGB1BS 

Two  programs  were  reviewed  in  order  to  deteraine  which 
possesses  the  largest  nuaber  of  desired  properties  and  still 
would  reguire  the  least  effort  to  ensure  system  compati¬ 
bility  with  the  current  version  of  MDBS.  The  first  of  the 
twc  prograas  was  originally  designed  in  [Bef.  3].  The 
second  was  a  latter  atteapt  to  siaplify  the  test  file  gener¬ 
ation  package. 

1.  The  Original  Test  Pii§  Genera  tion  Package 

In  this  program  the  test  data  is  generated  and 
stored  in  files.  Several  character istcs  of  the  file  are 
specified  by  the  experimenter.  Bach  file  is  given  a  name. 
The  data  in  the  records  is  specified  in  a  fixed  nuaber  of 
attribute-value  pairs.  The  type  of  data  in  the  attributes 
is  integer,  string,  and  floating-point  numbers.  These 
values  are  generated  in  either  predetermined  files,  called 
sets,  created  by  the  experimenter,  or  are  randomly  generated 
by  separate  functions.  Only  a  uniform  distribution  of  the 
various  data  types  is  available.  This  program  contains  all 
of  the  desired  properties  stated  above,  except  the  ability 
to  guarantee  uniqueness  of  the  records  created. 

2.  Tfre  Shortened  Test  F^le  Gener  ation  Package 

This  program  was  written  in  order  to  reduce  the 
complexity  of  the  original  test  file  generation  package. 
Many  of  the  features  of  the  original  program  remain  intact. 
Two  important  differences  exist.  The  shortened  version  only 
allows  the  use  of  predetermined  sets  of  values  to  be  used, 
therefore  not  allowing  randomly  generated  values.  The 
second  difference  is  the  fact  that  the  files  generated  must 
be  of  length  of  less  than  or  equal  to  10,000  records.  &n 
advantage  of  the  shortened  version  is  that  it  is  combined 
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with  the  shortened  database  load  program,  which  is  discussed 
in  the  following  section. 

D.  SELECTION  OF  THE  TEST  FILE  GENEBATIOH  PACKAGE 

The  shortened  version  of  the  test  file  generation 
package  was  selected  initially  as  the  file  generation  tool. 
HDES  is  currently  undergoing  a  change  in  the  version  of  the 
compiler  used.  In  an  attempt  to  keep  the  conversion  of  MDBS 
simple,  the  shortened  version  was  chosen.  This  version 
allowed  a  rapid  conversion.  However,  only  user  defined  sets 
of  values  are  selected  for  the  attribute  values.  This  is 
considered  a  disadvantage.  Perhaps  the  overriding  consider¬ 
ation  in  the  selection  of  the  shortened  version  was  the  fact 
that  its  associated  database  load  subsystem  was  much 
siapliar.  The  discussion  of  this  subsystem  is  provided  in 
detail  in  the  following  section. 

E.  THE  OPGHADIHG  PROCESS 

The  upgrading  process  for  the  shortened  version  of  the 
test  file  generaticn  package  was  relatively  simple.  The  C 
compiler  originally  used  in  the  implementation  was  an  older 
version.  The  new  version  is  being  used  by  MDBS.  Several 
minor  compiler  differences  with  respect  to  acceptable  syntax 
were  rapidly  fixed. 

F.  FUTURE  IHPR07EHEITS 

Because  the  shortened  version  possesses  all  but  one  of 
the  desired  properies  discussed  in  chapter  II,  only  one 
future  change  is  anticipated. 

Two  approaches  which  provide  the  shortened  version  with 
the  capability  of  randomly  generating  values  exist.  The 
first  of  these  alternatives  includes  adding  the  functions  to 
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the  prograi  with  the  additional  user  interface  to  select 
these  as  options.  The  second  alternative  is  to  adapt  the 
original  test  file  generation  package  to  be  compatible  with 
the  shortened  database  load.  The  task  would  be  simplified 
by  choosing  the  first  alternative. 

This  concludes  the  discussion  of  the  test  file  genera¬ 
tion  tool.  In  the  following  chapter,  we  discuss  the  proper¬ 
ties  of  the  selected  database  load  subsystem. 
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In  this  chapter,  we  discuss  the  database  load  subsystem 
development.  In  the  first  two  sections,  we  review  the 
purpose  and  desired  properties  of  the  subsystem.  In  the 
next  two  sections,  we  discuss  how  the  basic  progran  was 
selected  froa  existing  database  load  tools.  Pinally,  in  the 
last  two  sections,  we  discuss  the  upgrading  of  the  selected 
prograa  and  future  echanceaents  which  will  further  aid  the 
performance  evaluation  teaa. 

i.  THE  P DEPOSE 

The  database  load  subsystem  is  a  software  tool  used  to 
designate  an  input  source  file  and  to  create  a  database  from 
that  source  file.  It  also  allows  several  related  files  to 
be  consolidated  into  one  database  if  desired.  The  first 
phase  in  the  database  load  subsystem  is  to  define  the  input 
files  and  the  database.  The  second  phase  consists  of 
constructing  various  directory  management  tables.  Lastly, 
the  records  are  distributed  across  the  backends. 

B.  DESIRED  PBOPEBTIBS 

The  database  load  subsystem  must  be  designed  so  that  the 
performance  evaluation  may  utilize  various  cluster  formation 
variables  and  storage  variables  with  minimum  effort.  The 
performance  may  be  expected  to  depend  upon  whether  the 
number  of  descriptors  (attributes)  is  large  or  small.  The 
ease  of  specifying  the  descriptors  (attributes)  must  be 
guaranteed.  The  variation  of  cluster  size  may  affect 
perforaance.  The  cluster  size  is  a  function  of  the  number 
of  descriptors,  the  size  of  the  input  files,  and  the  values 
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used  in  the  attribute  fields.  These  three  parameters  should 
be  entered  independently.  The  data  placeaent  strategy, 
i.e.,  hov  records  are  distributed  across  the  backends,  also 
affects  performance.  The  ability  to  change  the  placement 
strategy  will  provide  a  means  of  confirming  simulation 
studies . 

C.  Eli ST I HG  PBOGBiBS 

Two  database  lead  subsystems  were  reviewed.  In  this 
section  the  merits  of  both  of  the  existing  programs  are 
discussed.  The  original  database  load  subsystem  is  covered 
first,  then  a  shortened  version  of  the  database  load 
subsystem  is  evaluated. 

1.  The  Original  Database  load  Subsystem 

The  original  database  load  subsystem  was  first 
designed  at  the  beginning  of  the  implementation  stage  of 
MDBS.  The  process  is  viewed  as  four  logical  phases.  The 
first  phase  is  the  database  definition  phase,  in  which  the 
user  specifies  various  characteristics  of  existing  source 
files  and  the  characteristics  of  the  database  to  be  created. 
The  second  phase  is  the  record  preparation  phase,  in  which 
the  data  is  read  from  the  input  files  and  prepared  for 
loading.  The  third  phase  is  the  record  clustering  phase,  in 
which  the  prepared  records  are  sorted  into  clusters.  The 
last  phase  is  the  record  and  table  distribution  phase.  This 
phase  distributes  the  records  and  the  directory  management 
tables  to  the  backends. 

2.  The  Shortened  Database  load  S  ubsvstem 

&s  stated  in  Chapter  II,  the  shortened  database  load 
subsystem  is  such  simpler  than  the  original  database  load 
subsystem.  This  implementation  can  be  viewed  as  two  phases. 
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The  first  phase  is  the  directory  table  construction  phas%, 
in  which  specified  database  paraaeters  are  read  from 
existing  files  and  the  directory  tables  are  constructed. 
The  second  phase  is  the  record  distribution  phase.  In  this 
phase  the  records  are  distributed  to  the  backends  by  using 
insert  requests.  Thus  this  subsystem  uses  currently 
existing  directory  sanageaent  functions  to  load  the  database 
records. 

D.  THE  SBIECTIOH  Of  THE  DATABASE  LOAD  SUBSYSTEM 

Several  disadvantages  to  the  original  database  load 
program  exist.  Since  it  was  created  at  the  inception  of 
HDES  design,  it  possessed  many  system  incompatibilities  with 
the  current  version  of  MDBS.  Once  again  the  large  size  of 
the  program  posed  a  significant  maintenance  problem  with 
respect  to  the  conversion  of  the  system  to  the  new  compiler. 
For  these  reasons  this  program  was  not  selected. 

The  shortened  version  of  the  database  load  subsystem  was 
chosen  as  the  basis  for  the  database  load  tool.  This  was 
due  to  the  fact  that  it  used  existing  directory  management 
code  and  that  it  was  much  simpler  to  understand  and  thus 
maintain. 

E.  THE  UPGBADI1G  PHOCESS 

In  this  section,  we  now  discuss  the  upgrading  of  the 
shortened  version  of  the  database  load  subsystem.  A  discus¬ 
sion  of  the  communication  among  processes  is  presented. 
Then  the  changes  to  the  database  load  subsystem  are 
discussed. 
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1 .  fll5SasS  E  §531^3 

In  order  to  load  the  current  version  of  MDBS,  it  is 
necessary  to  change  the  database  load  subsystea  so  that  it 
could  coaeunicate  with  the  backend  process  of  dirsc-cory 
■anageaent.  The  database  load  subsystea  is  implemented  as  a 
separate  process  in  the  controller.  k  brief  discussion  of 
aessage  passing  in  MDBS  is  presented  below. 

a.  Message  Passing  Within  a  Backend 

The  backends  are  supported  by  PDP-11/44S  running 
under  HSX-11M  operating  systea.  The  inter-process- 
coaauni cation  facility  is  the  shared  access  to  physical 
aemory.  Suppose  process  X  wants  to  send  a  aessage  to 
process  T.  X  will  copy  the  aessage  into  the  shared  area. 
Then  X  tells  the  operating  systea  to  send  the  address  of  the 
message  to  process  Y.  When  Y  is  ready  to  receive  a  message, 
it  gets  the  address  of  the  message  from  the  operating 
system's  gueue  of  such  addresses.  Process  Y  then  copies  the 
aessage  into  its  own  aemory  space. 

b.  Message  Passing  Within  the  controller 

The  HDES  controller  is  a  VAX-11/780  using  the 
VMS  operating  system.  The  inter-process  communication 
facility  is  the  mailbox.  The  aailbox  is  a  software  input/ 
output  device.  If  process  X  wishes  to  send  process  Y  a 
aessage,  process  X  first  issues  a  send  comaand  to  process 
Y's  aailbox.  When  process  Y  issues  the  read  comaand  on  its 
aailbox  it  will  be  given  the  aessage  sent  by  process  X.  The 
aailbox  can  queue  several  messages. 
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c.  Message  Passing  Between  Coapaters 

Coaaanication  between  coapaters  in  MDBS  is 
achieved  by  using  a  time-division-multiplexed  bus  called  the 
parallel  coaaanication  link  (PCI).  Two  interface  processes 
to  the  PCI  are  used  in  each  coapater.  The  first  process, 
called  put.PCL,  pets  the  aessage  to  be  sent  to  the  other 
coapaters  on  the  PCI.  The  seccnd  process,  called  get_PCL, 
receives  the  aessage  froa  the  bus  and  then  passes  the 
aessage  to  the  appropriate  process.  PCLs  are  presently  used 
to  siaulate  the  broadcast  bus  and  will  be  replaced  physi¬ 
cally  by  a  broadcasting  bus  later. 

2.  Pjiegtgsi  Tables 

Several  directory  tables  exist  in  order  to  process 
requests.  In  this  section  the  logical  descriptions  of  such 
tables  are  discussed.  This  will  allow  soae  insight  into 
what  kind  of  aessages  oust  be  sent  during  the  loading  of  the 
database. 

The  Attribute  Table  (AT)  contains  a  list  of  the 
directory  attributes  and  a  pointer  to  the  descriptors 
defined  on  these  attributes.  The  AT  is  located  at  each 
backend.  The  Descriptor-to-Cescri  ptor-Id  (DDIT)  Table 
contains  the  descriptors  and  their  corresponding  descriptor 
ids.  Bach  section  of  the  DDIT  is  associated  with  a  direc¬ 
tory  attribute  and  contains  the  descriptors  defined  on  that 
attribute.  The  DDIT  is  located  at  each  backend.  since 
type-C  sub-descriptors  are  created  dynamically  as  new 
records  are  inserted,  the  type-C  attributes  must  be  recorded 
in  a  table  called  the  Type-C-Descriptor-Table  (TCDT)  .  The 
TCDT  is  located  in  the  controller.  When  an  insert  request 
contains  a  record  with  a  type-C  attribute  and  the  value  of 
the  attribute  does  not  appear  in  a  type-C  descriptor,  a  new 
type-C  descriptor  will  be  created  by  the  Insert  Information 
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Generation  process.  This  process  will  then  record  the 
descriptor  in  the  TCDT.  Thus  all  directory  attributes  and 
their  corresponding  descriptors  are  sent  to  the  backend's 
Directory  Management  processes.  All  type-C  attributes  are 
also  sent  to  the  Insert  Inforaation  Generation  process  in 
the  controller. 

3.  Specific  Dporades 

The  database  load  subsystem  program  was  changed  by 
allowing  it  to  communicate  with  the  backends  in  order  to 
load  the  database  to  the  backends.  In  order  zo  distribute 
the  directory  management  tables  to  all  backends,  the  data¬ 
base  load  subsystem  must  be  given  its  own  mailbox  and  access 
to  the  directory  management  physical  areas  located  in  the 
backends.  All  of  the  functions  which  create  the  directory 
management  tables  were  moved  tc  the  backends  and  appropri¬ 
ately  placed  in  the  directory  management  processes.  Data 
necessary  to  construct  these  tables  was  passed  to  the  back¬ 
ends  by  using  messages  containing  codes  which  indicate  the 
type  of  action  to  be  taken.  Because  the  backends  can 

construct  the  tables  in  parallel,  this  did  not  significantly 
burden  the  database  lead  process.  In  order  to  support  the 
message  passing  ability,  send  and  receive  routines  specific 
to  the  database  lead  process  were  written.  Pigure  4. 1 
illustrates  the  inter-process  communication  involved  with 
the  directory  table  construction  phase. 

In  order  to  load  the  records  into  the  database, 
communication  between  the  request  preparation  process 
(located  in  the  controller)  and  the  database  load  subsystem 
was  established.  This  allowed  the  database  load  subsystem 
to  send  the  insert  requests  directly  to  request  preparation. 
Thus  the  database  load  subsystem  was  given  access  to  the 
request  preparation  mailbox.  it  was  also  necessary  to  send 
the  Insert  Inforaation  Generation  process  all  of  the  type-C 
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attributes  for  insertion  into  the  TCOT.  Figure  4.2  shoes 
the  inter-process  conaunication  of  the  record  distribution 
phase. 

The  following  is  a  summary  of  the  types  of  messages 
which  were  added  to  the  database  load  subsystem: 


Message  type:  (1)  Create  AT 

Source:  Database  Load  (CEL) 

Destination:  Directory  Management 

Explanation:  This  message  creates  an  AT  for 
the  given  database  name. 

Message  type:  (2)  Add  Attribute  to  AT 
Source:  Database  Load  (D8L) 

Destination:  Directory  Management 

Explanation:  This  message  adds  an  attribute 

to  the  at  for  the  given  database. 

Message  type:  (3)  Add  Descriptor  to  DDIT 
Source:  Database  Load  (EBL) 

Destination:  Directory  Management 

Explanation:  This  message  adds  a  descriptor 

to  the  DDIT  for  the  given  database. 

Message  type:  (4)  Add  the  end  cf  descriptor  flag 
Source:  Database  Load  (DBL) 

Destination:  Directory  Management 

Explanation:  This  message  adds  the  flag  to  signal 

the  end  of  the  descriptor  list. 

Message  type:  (5)  load  type-C 

Source:  Database  Load  (DBL) 

Destination:  Insert  Information  Generation 

Explanation:  This  message  passes  the  type-C  attribute 

to  IIG  for  entry  into  the  TCDT. 


Figure  4.2  CCHHOMICATIO MS:  RECORD  LOADING 


Message  type:  (6)  Insert  record 
Source:  Database  Load  (CEL) 

Destination:  Beguest  Preparation 

Explanation:  This  message  sends  the  record  to  be 

loaded  to  BP. 

Message  type:  (7)  Responses 

Source:  Directory  Management  and 

Insert  Information  Generation 
Destination:  Database  Load 

Explanation:  This  group  of  messages  informs  DBL  of 
action  that  is  actually  carried  out  as 
requested  by  the  above  messages  from 
DBL.  They  also  include  error  messages. 

Thus  for  each  of  the  messages  (1)  through  (6)  ,  a  type  (7) 
message  is  sent  tc  the  Database  lead  subsystem.  This 
concludes  the  upgrading  of  the  database  load  subsystem. 

P.  POT OB I  IMPROVEMENTS 

The  database  load  subsystem  contains  all  of  the  desired 
properties  discussed  above  with  the  exception  of  the  ability 
to  change  the  data  placement  strategy.  Due  to  the  manner  in 
which  the  database  is  loaded,  this  would  require  a  change  in 
the  directory  management  process.  Further  research  is 
required  to  investigate  the  ramifications  of  changing  the 
directory  management  process.  This  feature  should  be 
delayed  until  the  system  conversion  to  the  new  compiler  is 
completed. 


I.  Iflg  TEST  BBQOEST  GBHBB1TI01  PICK  AGE 


In  this  chapter,  we  discuss  the  test  request  generation 
package  development.  In  the  first  two  sections,  we  review 
the  purpose  and  desired  properties  of  the  package.  In  the 
next  two  sections,  we  discuss  how  the  basic  program  was 
selected  froe  existing  request  generation  tools.  Finally, 
in  the  last  two  sections,  we  discuss  the  upgrading  of  the 
selected  progras  and  future  enhancements  which  will  further 
aid  the  performance  evaluation  team. 

A.  THE  P DEPOSE 

The  purpose  of  the  test  request  generation  package  is  to 
provide  an  easy  means  of  creating  a  list  of  test  requests 
which  will  be  executed  in  order  to  test  NDBS.  The  package 
also  aids  the  evaluation  team  in  executing  the  list  of 
reguests.  The  list  of  requests  are  saved  in  a  file  for 
future  use,  in  order  to  avoid  regenerating  the  list  of 
requests. 

B.  DBS IB ED  PROPIBTIBS 

Becall  that  the  test  request  generation  package  permits 
the  request  formation  variables  to  be  altered  by  the  evalua¬ 
tion  team.  This  allows  the  following  to  be  varied:  the 

percentage  of  the  types  of  requests  (retrieve,  update, 
insert,  or  delete) ,  the  percentage  of  aggregate  operators 
(ave,  max,  min,  sum,  and  count)  in  retrieve  requests,  the 
complexity  of  the  request  query,  the  order  of  the  predicates 
appearing  in  the  request,  and  the  number  of  attributes  to  be 
projected  in  the  retrieve  request. 
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The  request  generation  package  must  also  possess  the 
ability  tc  allow  the  following  Modifications:  vary  the 

length  of  the  transaction,  tag  requests  with  user  identifi¬ 
cation,  retrieve  a  record  defined  over  the  null  descriptor, 
and  execute  a  retrieve  request  in  which  the  entire  cluster 
is  stored  at  one  backend  and  ccapare  the  performance  with  a 
request  which  retrieves  records  from  a  cluster  which  is 
stored  across  all  backends. 

C.  SZISTIB6  PRCGB1HS 

Two  existing  programs  were  reviewed  in  order  to  select 
the  one  which  best  fits  the  desired  properties  and  is  compa- 
tibile  with  the  current  version  of  MDBS.  Both  programs 
implement  the  test  request  generation  package  in  the 
controller.  The  next  section  discusses  version  A  of  the 
test  request  generation  package.  Version  A  was  originally 
designed  at  the  commencement  of  the  implementation  of  MDBS. 
Version  B  was  a  later  version. 

1 .  Version  A 

Version  A  may  be  described  as  a  package  which  aids 
the  user  in  developing  a  list  of  requests.  The  user  is 
guided  through  the  construction  of  one  reguest  at  a  time. 
The  program  ensures  that  the  syntax  is  correct.  The  intent 
of  this  method  is  to  generate  a  small  number  of  requests 
which  are  thoughtfully  devised  in  order  to  test  specific 
features  cf  MDBS.  This  program  also  assumes  that  one  user 
will  execute  only  one  request  at  a  time.  The  user  is 
allowed  the  following  options  when  using  this  t9st  request 
generation  package:  generating  a  list  of  requests  for  later 
use,  retrieving  a  list  of  requests  to  be  executed  in  any 
order,  modifying  an  existing  list,  or  executing  a  list  of 
requests. 
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2.  Version  B 

Version  B  is  a  follow-on  package  to  Version  A.  It 
therefore  possesses  all  of  the  features  contained  in  Version 
A.  It  should  be  noted  that  Version  B  adds  the  ability  to 
use  the  concept  of  transactions.  Hecall  that  a  transaction 
is  a  group  of  one  cr  sore  requests.  Thus  the  requirement  of 
executing  only  one  request  at  a  time  is  remowed. 

O.  THE  SELECTIOH  OF  THE  TEST  BEQUEST  GENERATION  PACKAGE 

Because  Version  B  contains  all  the  features  of  Version 
A,  Version  B  was  selected  as  the  test  request  generation 
package.  Because  this  version  arrived  at  the  current  imple¬ 
mentation  site  cf  MDBS  rather  late  in  the  review  of  perform¬ 
ance  evaluation  tools,  many  of  the  desired  features  must  be 
left  for  future  development.  This  does  not  detract  from  the 
usefulness  of  the  test  request  generation  package  as  it 
stands. 

E.  THE  UPGRADING  PBOCESS 

The  majority  of  the  upgrading  accomplished  on  the  test 
reguest  generation  package  consisted  of  ensuring  that  the 
syntax  discrepancies  due  to  compiler  differences  were 
removed.  A  reorganization  of  the  file  location  of  MDBS 
resulted  in  many  changes  to  the  programs. 

F.  FUTURE  IHPR0VEHS1TS 

Several  enhancements  to  the  request  generation  package 
may  be  desirable.  Three  major  enhancements  include  the 
following;  program  generation  of  requests,  simulation  of 
mutltiple  concurrent  users,  and  development  of  a  storage 
information  package  to  aid  in  request  selection. 
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i-  Eiagiaa  Sifisiat^2B  21  Igasests 


In  order  to  test  MDBS ,  the  test  request  generation 
package  could  be  modified  to  contain  a  routine  which  gener¬ 
ates  random  requests.  The  input  to  such  a  routine  would 
include  parameters  such  as  the  percentage  of  each  type  of 
request  to  be  generated  and  the  the  query  complexity.  Query 
complexity  involves  changing  tie  number  of  predicates  in  the 
requests.  This  ability  would  allow  the  evaluation  team  to 
easily  determine  which  type  of  request  is  most  efficient 
under  HOBS. 

2.  Simulation  of  Multiple  Concurrent  Psers 

In  order  to  evaluate  the  effect  of  concurrency 
control,  HOBS  must  be  tested  while  several  users  are  using 
the  system.  By  providing  a  way  to  link  a  user  to  the 
requests  which  are  generated,  the  test  request  generation 
package  would  simulate  mutiple  users.  This  would  avoid 
processing  several  separate  files  of  requests.  This  would 
also  result  in  repeatable  experiments,  in  that  the  condi¬ 
tions  resulting  frcm  executing  the  concurrent  user  requests 
could  be  duplicated. 

3.  The  Storage  Information  Package 

The  storage  information  package  would  allow  the 
experimenter  to  ask  specific  questions  about  the  database 
storage  information  so  that  intelligent  queries  can  be 
derived.  The  questions  an  experimenter  night  ask  would 
include:  Rhat  descriptors  are  associated  with  a  certain 

attribute?  Rhat  descriptor  ids  define  a  certain  cluster 
number?  or  Rhere  is  cluster  one  stored? 

This  package  could  be  implemented  by  sending 
messages  to  the  backends.  Bach  message  would  be  associated 
with  a  routine  which  walks  through  the  directory  management 


tables  and  finds  the  appropriate  inforaation  and  sends  it 
back  to  the  controller.  By  evaluating  the  responses  to  the 
aessages,  aore  aeaningful  re  guests  can  be  constructed  in 
order  to  evaluate  specific  features  of  HDBS. 
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VI.  4JAU5I5  SI  £SH£2ISIBSS  SIAMmgl  I22&S 


In  Chapter  I,  we  discussed  the  stud;  phase  of  creating 
the  tools.  In  Chapter  II,  ve  discussed  the  design  phase. 
The  development  phase  was  outlined  in  Chapters  III,  17,  and 
7.  In  this  chapter,  we  discuss  the  operational  phase.  This 
taxonomy  of  phases  is  outlined  in  detail  in  [Bef.  8].  More 
specifically,  in  this  chapter,  ve  discuss  the  performance 
evaluation  tools  with  respect  to  several  software  engi¬ 
neering  principles. 

i.  BASIS  OF  AB1LISIS 

In  this  section,  we  discuss  the  standards  by  which  the 
evaluation  tools  are  to  be  analyzed.  The  two  major  catego¬ 
ries  of  the  analysis  are  the  ability  to  meet  the  objectives 
stated  in  the  design  phase  and  the  ability  to  aee-  software 
goals.  The  standards  ars  described  in  detail  in  [Bef.  9] 
and  [Bef.  10]. 

The  ability  to  meet  objectives  means  that  the  tool  poss¬ 
esses  the  capabilities  outlined  in  the  design  phase.  These 
capabilities  were  discussed  in  detail  in  Chapter  II. 

The  performance  evaluation  tools  will  be  evaluated  also 
by  their  ability  to  meet  five  software  goals.  The  first 
goal  is  that  of  modifiability.  Modifiability  includes  the 
properties  of  extensibility,  consistency,  maintainability, 
and  modularization.  The  second  goal  is  that  of  reliability. 
Reliability  includes  the  properties  of  possessing  no  blatent 
errors  and  of  possessing  error  recoverability.  The  third 
goal  is  simplicity.  This  includes  ease  of  use  and  single¬ 
ness  of  purpose.  Efficiency  is  the  fourth  goal.  A  tool 
will  possess  this  goal  if  it  contains  no  gross  inefficiency. 
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The  last  software  goal  is  that  of  under standabili-y . 
Understandability  Beans  that  the  tool  utilizes  abstractions, 
Modularity,  and  information  hiding,  and  is  supported  with 
reasonable  docuBentation. 

B.  AHALlSlS  OF  TBS  FILE  GSIBBITIOtr  PACKAGE 

The  objectives  of  the  file  generation  package  were 
discussed  in  Chapter  II.  The  objective  that  was  not  aet  by 
this  tool  is  the  ability  to  indicate  whether  values  of  the 
attributes  are  taken  froa  random  functions  or  predetermined 
sets  of  values..  The  randoa  functions  oust  be  added  at  a 
future  date. 

The  file  generation  package  meets  all  goals  with  the 
exception  of  efficiency.  Modifiability  is  achieved  through 
the  extensive  use  of  modular ization  with  respect  to  grouping 
like  operations  together.  Reliability  has  been  observed  in 
that  no  errors  have  existed  since  the  operational  phase. 
Simplicity  is  demonstrated  by  using  menu-driven  operations 
in  the  file  generation  package.  Lastly,  understandability 
is  achieved  by  religious  use  of  abstraction  of  data  and 
operation.  The  gross  inefficiency  in  the  package  results 
froa  the  use  of  a  large  array  which  is  used  to  store  the 
unique  records  which  are  generated.  Bhen  a  large  number  of 
records  are  to  be  inserted  at  one  time,  the  time  to  compare 
the  new  record  against  all  previously  generated  records  is 
great.  This  concludes  the  evaluation  of  the  test  file 
generation  package. 

C.  ABALYSIS  OF  TBS  DATABASE  LOAD  SOB SYSTBH 

The  objectives  cf  the  database  load  subsystem  were 
discussed  in  Chapter  II.  The  objective  that  was  not  aet  by 
this  tool  is  the  ability  to  vary  the  data  placement 
strategy.  This  ability  must  be  added  at  a  future  date. 


The  database  load  subsystea  aeets  all  goals  with  the 
exception  of  efficiency.  Modifiability  is  achieved  through 
the  extensive  use  of  aodalar ization  with  respect  to  grouping 
like  operations  together.  For  instance,  all  of  the  routines 
to  pass  aessages  are  grouped  in  send  and  receive  modules 
which  are  kept  in  separate  files.  Reliability  has  been 
observed  in  that  no  errors  have  existed  since  the  opera** 
tional  phase.  Siaplicity  is  deaonstrated  by  using  aenu- 
driven  operations.  Lastly,  understan dability  is  achieved  by 
religious  use  of  abstraction  both  in  the  data  and  the  opera¬ 
tions.  The  gross  inefficiency  in  the  package  results  fron 
the  use  of  a  large  nuaber  of  insert  reguests  which  are  sent 
one  at  a  tiae  to  the  backends.  This  inefficiency  could  be 
reduced  by  grouping  several  insert  requests  into  a  trans¬ 
action  and  then  sending  the  transaction  to  tha  backends.  It 
is  also  possible  tc  save  all  type-c  descriptors  in  the  data¬ 
base  load  subsystea  and  send  all  cf  thea  to  Insert 
Inforaaticn  Generation  at  the  end  of  the  directory  table 
loading.  This  concludes  the  evaluation  of  the  database  load 
subsystea. 

D.  iliLTSIS  OF  THE  BEQUEST  GBHEB1TI0H  PICK  AGE 

The  objectives  of  the  test  request  generation  package 
were  discussed  in  Chapter  II.  The  objectives  that  were  not 
aet  by  this  tool  are  the  following  enhanceaents:  program 

generation  of  requests,  siaulation  of  aultiple  concurrent 
users,  and  developaent  of  a  storage  inforaaticn  package  to 
aid  in  request  selection.  These  abilities  aust  be  added  at 
a  future  date. 

The  test  request  generation  package  aeets  all  goals  with 
the  exception  of  possessing  consistency.  Modifiability  is 
achieved  through  the  extensive  use  of  aodulari zation  with 
respect  to  grouping  like  operations  together.  For  instance. 
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all  of  the  routines  which  are  involved  with  creating  a 
request  are  divided  into  aodules  each  of  which  handles  a 
distinct  aspect  of  the  request.  This  goal  is  seen 
throughout  MDBS.  Reliability  has  been  observed  in  that  no 
errors  have  existed  since  the  operational  phase.  Sisplicity 

t 

is  deaonstrated  by  using  menu-driven  operations.  Lastly, 
underst andability  is  achieved  by  religious  use  of  abstrac¬ 
tion  both  in  the  data  and  the  operations.  Consistency  nay 
be  achieved  by  altering  the  test  request  generation  to  use 
infornation  stored  in  the  files  generated  by  both  the  test 
file  generation  package  and  the  database  lead  subsyten. 
These  files  could  be  used  for  the  extraction  of  necessary 
infornation  instead  of  pronpting  the  user  to  re-enter  data 
supplied  earlier.  It  is  the  weakest  link  in  establishing  a 
tight  perfornance  evaluation  environs ent.  This  is  further 
discussed  in  the  next  section.  This  concludes  the  evalua¬ 
tion  of  the  database  load  subsystem. 

■.  FUT OBI  DEVELOPMENTS 

The  most  important  future  development  should  be  the 
integration  of  the  perfornance  evaluation  tools  into  a 
performance  evaluation  environment.  In  this  way,  the  prop¬ 
erty  of  consistency  of  the  tools  will  be  attained.  That  is, 
the  output  of  one  tool  can  be  used  as  input  to  the  next  tool 
in  the  logical  sequence  of  the  performance  evaluation 
effort.  This  has  been  achieved  in  the  test  file  generation 
package-database  lead  subsytem  interface.  The  next  step 
would  be  to  develop  consistency  between  the  database  load 
subsyst em-test  request  generation  package  interface. 

This  concludes  the  discussion  on  the  analysis  of  the 
performance  evaluation  tools. 
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fll.  COHCIDSIOB S 


In  this  thesis,  we  have  discussed  the  development  cf  the 
necessary  tools  for  the  performance  evaluation  of  a  multi- 
backend  database  system,  known  as  HDBS.  The  basic  motiva¬ 
tion  of  the  autlti-backend  database  system  (M  DBS)  was  to 
develop  an  architecture  which  spreads  the  work  of  the  data¬ 
base  system  among  multiple  backends.  It  was  a  major  aim  cf 
this  systea  to  allow  capacity  growth  by  the  use  of  addi¬ 
tional  disk  drives  and  performance  improvement  by  the  use  of 
additional  backends.  However,  to  verify  the  design  and 
implementation,  it  is  necessary  to  test  the  capability  of 
HDBS  in  capacity  growth  and  performance  gain. 

Three  tools  for  the  perforaance  and  capacity  tests  were 
investigated.  The  first  tecl  was  the  file  generation 
package  which  creates  test  files  for  any  artificial  data¬ 
base.  The  second  tool  was  the  database  load  subsystem  which 
loads  the  artificial  database  into  HDBS.  The  third  tool  was 
the  request  generation  package.  This  package  created  test 
requests  to  query  HDBS. 

The  following  methodology  was  used  to  create  an  effec¬ 
tive  tool.  First,  the  properties  of  an  ideal  tool  were 
described.  Then  available  existing  programs  were  reviewed 
and  evaluated  to  determine  which  program  best  meets  the 
desired  features.  The  programs  were  upgraded  to  ensure  that 
they  were  compatible  with  the  current  implementation,  and 
met  the  desired  features.  Lastly,  the  tools  were  analyzed 
with  respect  to  meeting  the  desired  properties  and  satis¬ 
fying  several  software  engineering  goals. 

T\e  main  goal  was  to  develop  the  necessary  tools  to 
generate  tests  in  measuring  the  extensibility  of  HDBS,  i.e., 
how  does  HDBS  perform  as  more  backends  are  added? 


46 


Performance  was  expected  to  improve  (maintain)  as  the  number 
(size)  of  the  backends  (database)  was  increased.  we  feel 
that  the  tools  developed  herein  will  allow  an  easy  and  effi- 
cient  aeans  of  measuring  the  extensibility  of  MOBS. 
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APPBHPU  1 

OBSIGI  SPECIFICATION  OP  THE  TEST  FILE  GBBBIATION  PACKAGE 


This  appendix  contains  the  design  cf  the  test  file 
generation  package  which  is  a  subset  of  the  shortened  data¬ 
base  load  subsystea.  The  design  consists  of  C  language  code 
for  the  function  headings  and  their  corresponding  declara¬ 
tions.  The  body  of  the  functions  are  given  in  English  text. 


/*********************/ 

/♦  TEST  FILE  */ 

/*  GENE  E ATI ON  */ 

/*  PACKAGE  */ 

/*  DESIGN  */ 

/**************  *******/ 


aain  program () 
begin 

generate ()  ;  /*generate  the  records*/ 

end 


generate  () 

/*  This  routine 

A 

/* 


-  g®5®£®tes  ajj^c^rd  template 


-  gene  rates/ modifies  sets  of  values  for  attributes 

-  generates  descriptors 

-  generates  records  using  the  sets 


% 

*/ 


be9&lle 

begin 


(  THUS  ) 


/♦Ask  the  user, for  type  of  i 
/♦Take  appropriate  action*/ 
/*  generate  record 


end 


end  while; 


operation  to  be  performed*/ 

template  */ 

descriptors  */ 

/■*  'dehera^e/modify  sets  */ 
gaJUtO  ; 

/*  generate  the  records  */ 

'"U  records  */ 
ng*/ 


genet 

xen  tmpl  () ; 
>*  generate 
gen  desc  (} ; 

a 


gen  rec 
/,*  Jcad 

tos?ai 


db _ 

/*3o  no 
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gen_tapl() 

7*  This  routine  generates  a  record  template  */ 
begin 

char  tfn (HFHLength  *1):  /*  template-file  naae  */ 

char  c,  dbid  (DBIDLHTH+  1)  ,  hold {HA  X  FIELDS  +  1) ,  teatvp; 
int  i,  k,  no  attr;  “ 

FILE  *ropen  07  *tapl_fp; 

/*  Get  naae  of  teaplate  file  ♦/ 

/*  Open  teaplate  file  */ 

/*  Get  database  ID  froa  the  teaplate  file*/ 

/*  Write  database  ID  to  teaplate  file  */ 

/*  Get  nuaber  of  attributes  */ 

/*  write  nuafcer  of  attributes  to  teaplate  file  */ 

/*  Get  attributes  and  value  tyoes  */ 

for  (each  attribute) 

begin 

/*  Enter  the  attribute  name*/ 

/*  Enter  the  value  type:  (s=string,  i=integer)  */ 
end  /*  end  fcr  */ 

/*  Close  teaplate  file  */ 
end  /*  end  gen  tapl  */ 


gen_desc  () 

begin 
char 

char  _  _ ^ 

char  attr  naae  (AHLength, , 

answer  (7)  ,  desc  type,  val  type,  c. 


tfn (HFHLength  ♦  1 
dfn  (HFHLength  ♦  1 
ittr  naae  (AHLength 


/*  template-fils  name  */ 

/*  descriptor-file  name  */ 

hold (3)  ; 


int  i,  j,  nc_attr; 

FILE  *fopen  ()  ,  *tapl_fp,  *desc_fp; 

/*  Get  the  teaplate-file  naae  */ 

/*  Open  teaplate  fil9  */ 

/*  Get  the  naae  of  the  file  for  storing  descriptors  */ 

/*  open  descriptor  file  */ 

/*  Head  thru  Database  ID  to  get  */ 

/*  to  number  of  attributes  */ 

/*  Get  number  of  attributes  */ 

/*  For  each  attribute  gat  its  descriptors  (if  applicable)*/ 

for  (each  attribute) 

begin 

/*  Bead  attribute  */ 

/*  Get  attribute  naae  */ 

/*  Get  yalue  type  for  tne  attribute  */ 

/*  Ask  if  attribute 

is  to  be  a  directory  attribute*/ 
if  /  answer*  yes  ) 
begin 


/*  Write  attribute  naae  to  descriptor  file  */ 

*  Get  descriptor  type  for  attribute  */ 

*  Write  descriptor  type  to  descriptor  file  */ 


/* 

a 


*.  a.,criPtor 

end 

end  /*  end  fcr  */ 

/*  Write  end_of  file  syabol  to  descriptor  file  */ 
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r 


/*  Close  files  */ 
end/*gen_desc*/ 


gen_C(val_type,  desc.fp) 

char  val  type; 

FILE  *de2c  Ip; 
begin  " 

char  lowerb  (AVLength)  ,  upperb(AVLength)  ,  hoia(3)  ; 
int  fault,* ; 


/♦Get  upper  bounds  for  type  *c»  descriptors  */ 

while  (  TSOE  ) 

begin 

/♦  Get  upper  bound  ♦/ 
if  (  end  of  data) 
return ; 

/.  (Uilitii  5SJSI  ill?  entIJ  v 

/♦  write  HOBOOND  and  ypper  bound  */ 

/♦  to  descriptor  file  ♦/ 

end 
end 

end  /*  end  gen  C  */ 


g  en_no t  C ( v  al_t  y  p  e , d  es  c_f  p ) 

char  val  type; 

FILE  *des5  fp; 
begin 

char  lowerb  (AVLength)  ,  up  perb  (AVLength)  ,  hold(3)  ; 
int  fault,  k; 


iet  lower  and  upper  bounds  for  descriptor  */ 
*  (  THUS  ) 


/♦ 

while 
begin 

/♦  Get  lower  bound  ♦/ 
if  (  end  of  data) 
return; 
else 
begin 

/*  Verify  lower  bcund  entry  against  */ 
/♦  attribute  value  type  */ 

/♦  Write  lower  bound  to  descriptor  file  *> 

end 

/♦  Get  upper  bound  ♦/ 

/♦  Verify  upper  bound  entry  against  ♦/ 

/♦  attribute  value  type  */ 

,/*  Write  upper  bound  to  descriptor  file  */ 
end  /*  end  while  */ 
end/*  end  gen_notC  ♦/ 


g«_set() 

/*  This  routine  genecat es/sodif ies  sets  of  values.  */ 
begin 

char  tfn(HFH length  ♦  1)  ;  /♦  teaplate-file  naae  */ 
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char  attr  naae  (AHLength  ♦ 
hcldlAVLength  +1); 

k,  i; 

PILE  *fopen(),  *tmpl_fp; 


1),  answer,  c,  wal_type. 


/*  get  the  template-file  name  */ 

/*  Open  template  file  ♦/ 

/*  Get  number  of  attributes  ♦/ 
for  (  each  attribute  ) 
begin 

/*  Get  attribute  naae  */ 

/*  Get  walue  type  */ 

/♦  Choose  the  action  to  be  taken  on  attribute 

generate  a  new  set  for  it 
modify  an  existing  set  for  it 
do  nothing  with  it 


xoe  at 

1: 


switch (  answer  ) 
begin 

C&S  6  *  q  •  j 

/♦‘generate  new  set  */ 

Een  set(  val  type  ); 
reak ; 

t  H  9  e 

nod  set(val  type)  ; 
breik; 

9  g  t  e 

break; . 
end  /*  end  switch  */ 
end  /*  end  for  */ 

/♦  Close  template  file  V 
end  /*  end  gn  set  */ 


case 


case 


gen_set  (wal_type) 


ghar  val  type; 
begin 

struct  definition 
begin 

char  elea (Set Size)  (AVLength  ♦  1)  ; 

/♦  array  for  holding  set  elements  */ 
int  no  elea: 

/♦  nuoBer  of  elements  in  set  */ 

end  set; 


char  f ilna a (HFH length  ♦  1)  , 

entry  (iflengtfi  ♦  1),  answer (5)  ; 
int  k,  fault ,  liiit; 

PILE  *fopen(),  *tmpl_fp; 

/*  Get  naae 

/♦  open  set _ 

/*  Accept  elements 
while  (  set  is  not 
begin 

/*  Enter  a  walue  for 
/*  Verify  set  entr 
/*  Check  for  set 
end 


of  set  file  */ 
file  */ 


nt  V 
the  set  */ 

ry  against  attribute  type  ♦/ 
element  duplication  */ 


*/ 
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if  (  set  is  fall) 

/*  Tell  user*/ 

/*  Write  set  elements  to  set  file  */. 

/*  write  end  of  file  symbol  to  set  file  */ 
/*  Close  set"fiTe  */ 

/*  Ask  if  user  wants  to  modify  it  */ 
if  (  answer*  yes  ) 
aod  setfval  type); 
end  /*  end  gen  sef  */ 


aod  setfval  type) 

7*  This  routine  modifies  a  set  */ 
/*  of  values  for  an  attribute.  */ 


b.gftar 

char 


val_type ; 


ofn  (HFNlength  ♦  1)  ,  /* 
nfn  (HFHLength  ♦  1)  ,  /* 
filnam  (HFHLength  +  1) ; 


/*  old-file  name  */ 
/*  new-file  name  */ 


ghar  c,  answer (5),  entr y(AV Length  +  1),  index(5)  ; 
int  i,  k,  fault, j; 

struct 

begin 

int  no  elea;  /*  number  of  elements  in  the  set  */ 

char  red  flag  (SetSize)  ;  /*  element  removed  flaq  */ 
char  elei(SetSize)  (AVLength  ♦  1);  /*  elements  */ 


char  eleI(Sef  Size) 
end  set; 


ength  ♦  1)  ;  /*  elements  */ 


PILE  ♦fopen(),  *set_fp; 

/*  Get  the  name  of  the  set  tc  be  modified  */ 

/*  Open  file  */ 

/♦^Reaa  |iven  file  into  array  for  manipulation  */ 
begin 

/*  isk  what  do  you  want  tc  perform  next?*/ 

(p)  -  print  the  set  elements  and  their  indices 

fa)  -  add  some  elements  to  the  set 
(r)  -  remove  some  elements  from  the  set 

(n)  -  nothing;  done 

if  l  answer  *  'p'  j 
begin 

/*  Print  elements  of  file  */ 
end/*  end  (  answer  *  1  p'  )  */ 
else  if  (  answer  *  'a'  ) 
begin 

/*  Add  some  elements  */ 

/*  Check  for  set  element  duplication  */ 

/*  Verify  entry  against  */ 

/*  attribute  value  type  */ 

/*  Add  element  to  array  if  correct*/ 
end  /*  end  (  answer  *  »al  )  */ 
else  if  (  answer  *  ' r*  ) 
begin 

/*  Remove  some  elements  */ 

/*  Hark  set  elements  for  removal  */ 

/*  He-crdei  array  to  reflect  deletions  */ 
end  /*  end  (  answer  *  ' r'  )  */ 
else 


7*  nothing:  done  */ 
creak;  /*  exit  while 
'*  end  while  (  TRUE  )  */ 
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/*  Ask  if  user  wants  to  store  the  modified  set  back 
into  the  original  file  */ 

/*  Write  array  back  into  file  designated*/ 

/*  Write  end  of  file  symbol  to  set  file  */ 

/*  Close  seffile  */ 
end/*  end  mod  set  */ 


gen  rec  n 

7*  This  routine  generates  records  using  sets.  */ 
begin 

char  c ; 

char  hold (AVLength  ♦  1}  ; 
char  attr  name  (AVLength  ♦  1); 


char 

char 


dbid  (DBIDLNTH  *  1). 

gr  records  (HAX  RECORDS)  (HRLength  ♦  1); 
tfn  (HFNLengt b  T  1),  /*  template-file  name  */ 
rfn  (MFNLength  ♦  1),  /*  record-file  name  */ 
vfn  (HFNLength  +  1);  /*  temporary  file  name  */ 


struct 

begin 

int  no  elem  (MAX  FIELDS): 

char  eleas  (HAX  "FIELDS)  (SetSize)  (AVLength  *  1)  ; 
end  values; 

FILE  *fopen(),  *tmpl_fp,  *rec_fp,  *stor_fp; 

int  no  attr,  k,  i,  j,  count,  gr  no  rec,  max, 
reC_cnt,  prcd,  index,  old;  “  ” 

/*  Get  the  template-file  name  */ 

/*  Open  template  file  */ 

/*  Get  file  for  record  storage  */ 

/*  Open  record  file  */ 

/*  Read  database  ID  */ 

/*  Write  database  ID  to  storage  file  */ 

/*  Read  number  of  attributes  in  a  record  */ 

/*  Read  elements  of  files  corresponding  to  */ 

/*  each  attribute  into  an  array  */ 

for  (  each  attribute) 

begin 

/*  Read  the  attribute  name  */ 

/*  Get  the  file  name  for  the  given  attribute  */ 

/*  Open  file  */ 

/*  Read  elements  of  set  into  array  */ 

/*  Close  file  */ 
end  /*  end  for  */ 

/*  Close  template  file  */ 

/*  Calculate  total  possible  number  of  unique  records  */ 

/*  Get  the  number  of  records  to  be  generated  */ 

/*  Determine  feasibility  of  Requested  number  */ 

/*  Generate  records  by  choosing  (at  random)  */ 

/*  a  member  from  each  of  the  given  sets  */ 

for  (  each  record) 

begin 

for  (for  each  attribute) 
begin 

/*  Get  a  value  randomly  from  the  set*/ 
end 

/*  Give  some  feedback  tc  user  cf  generation  effort*/ 
/*  Check  generated  record  for  possible  duplication  */ 
end 

/*  Write  generated  records  to  file  */ 

/*  Write  end  of  file  symbol  to  file  */ 

/*  Let  user  Knol  when  completed*/ 
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/*  close  fils  */ 
end/*  and  gen_rec  */ 

int  gr_is digit  (c) 

/*  This  routine  detecaines  whether  a  given  */ 
/*  character  Is  a  digit  */ 

char  c ; 

(  c  is  a  diqit  ) 
return  (TBOEJ ; 
olso 

return (FALSE) ; 


g strand  (nua) 

/*  This  routine  generates  a  randoa  nuaber  */ 

int  nu  a ; 
begin 

static  long  seed; 
static  int  teac: 

seed  *  seed  *  *4 298  +  tear  +  tiae(O); 
seed  *  seedaod199017 ; 
seed  *  (69069  *  seed  +  1); 
ieap  *  (seed  >>  8)  6  32767; 


$eap  *  (seed  >>  8)  6  32767; 
if  (  nua  **  0  ) 
return (teap) ; 
else 

return  (teap  aod  nua)  ; 


L2S.Z&2U  £ 

DBS 161  SPECIFICATION  OF  THE  DATAB1SE  LOAD  SUBSTSTEH 


This  appendix  contains  the  design  o£  the  shortened  data* 
base  load  subsystea.  The  design  consists  of  C  language  code 
for  the  function  headings  and  their  corresponding  declara- 
tions.  The  bod;  of  the  functions  are  given  in  English  text. 

/****************  */ 

/*  */ 

/*  Database  Load  */ 

/*  Design  */ 

/****************  */ 


struct  rteap_def inition  teaplate; 


db  load  () 

/♦“This  routine  loads  the  directory  tables  and 

/*  records. 

begin 

/*  initialize  counters*/ 

/*  load  the  directory  tables  */ 
dbl  dir  tblsn  : 

/*  load” the  database  records  */ 
dbl  records  0; 

end 


the  database 


*/ 

*/ 


dbl  dir  tbls() 

/*  This  routine  loads  the  directory  tables.  */ 
begin 

char  dbid  (DBIDLNTH  ♦  1 
attrnaae (AHLength 
tfn  (HFNLength  ♦  1 
dfn  (HFNLength  *  1 
▼alt  ype, 
str  (f , 

attrstr(DII  Attrld  +1) , 
desctype; 

int  at_id_.no,  desc_id_no; 

struct  desc_daf  inition  descriptor; 

int  i,  k,  c; 

FILE  *fopen(),  *fptr; 


)  » 
♦ 


1), 

/*  tea  plate-fils  naae  */ 

/*  dsscriptor-f ile  name  */ 


/*  Initialize  the  database  aailbox*/ 

/*  Get  the  naae  cf  the  file  containing  */ 
/*  the  teaplate  lnforaatlon  */ 

/*  Read  the  database  id  */ 
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/*  Bead  naaber  of  entries  in  the  teaplate,  i.e.,*/ 
/*  naaber  of  attributes  in  a  record  */ 
/*  Bead  the  attribute  naaes  and  the  value  types  */ 
/*  and  place  the  data  in  the  teaplate  record  */ 
for  (  each  attribute  to  be  put  in  teaplate) 


begin 

/*  Bead  an  attribute  */ 

/*  Bead  the  corresponding  value  type  */ 

end 

/*  Create  attribute  table  fcr  the  database  in  backends  */ 
DBL  S$Create  (dbid)  ;  t  . 

/*  Get  the  naae  cf  the  file  containing  the  descriptors  */ 
/*  Bead  the  directory  attributes  and  their  */ 

/*  corresponding  descriptors  */ 

/*  Initialize  the  attribute  counter  */ 

while  (  not  the  end  of  data  ) 

begin 

/*  Bead  an  attribute  */ 

/*  Bead  corresponding  descriptor  type  A,  B,  or  C  */ 
/*  Add  the, attribute  naae  to  the  attribute  table  */ 
DBL  stAta  insert  (dbid, attrnaae,&desctyDe)  ; 

he  at+i 


cbl  ssAta  insert  (dbid^attrna ae# Bdesctyoe)  ; 
if  fdesctype  ®  rc'  l  desctype  «*  '  C')' 

7*  Send  the  attribute  to  IIG  */ 

DBL  Sssend  typeC fdbid ,attrnaae,at  id  no); 

/*  Using  the  teaplate.  find  the  value  */“  “ 

/*  type  for  the  attribute  */ 

/*  Bead  the  corresponding  descriptors*/ 

/*  for  the  attribute  */ 

/*  Inititialize  the  descriptor  id  */ 

while  (  Bore  descriptors  ) 

begin 

/*  Get  lower  bound  */ 

/*  Get  upper  bcund  */ 

/*  Add  the  descriptor  to  DDIT  */ 

DBL  SSDesc  add  (dbid.a  ttrname.&desctype. 

Edescriptor.Svaltype, at  id  no,desc  id  no); 
/*  Increaent  the  descriptor  id  count  */ 
end  /*  end  while  */ 
if  (  desctype  )=  C  ) 
begin 

7*  Add  the  catchall  descriptor  to  DDIT  */ 

DBL  SSCetchall  (dbid,attrnaae. 

6desctype,at  id  no,desc  id  no); 
end  /*  end  if  */  ~ 

/*  Increaent  the  attribute  count  */ 
end  /*  end  while  */ 

/*  close  descriptor  file  */ 
end/*  end  abl  air  tbls  */ 


dbl  records () 

b€  cfiar  dbid  (DBIDLHTH  ♦  1), 

rfn  (aFNLength  +  1)#  /*  record-file  naae  */ 

struct  rteap  definition  *tapl  ptr, 

.  .  .  ♦g«O«Pl-Ptr0  ; 

int  i,  c; 


struct  rteap_< 


FILE  *fopen(),  *fptr; 

/*  Get  the, naae  cf  the  file  */ 

/*  containing  the  records  to  be  loaded  */ 

/*  Bead  the  database  id  */ 

/*  Get  the  record  teaplate  for  the  database  */ 
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while 

begin 


end 
end  /♦ 


(  aore  records  exist  ) 

/*  while  there  are  sore  records  */ 

/*  Bead  the  next  one  */  ,  _ 

/*  construct  a  request  to  insert  record  ♦/ 
abl  construct  ins  (  tapl  ptr,  record,  req  ): 

/♦  5ena  the  request  tc  le quest-preparation  */ 
cBL_S$Trafanit(dbid,  req)  ; 

end  dtl_records  */ 


dbl_construct_ins(taplj?tr,  record,  req) 


struct  rtea^_def  initio  n  *tapl_ptr; 


req 


record  ()  ; 


char 
begin 

Int  i,  j,  k,  p,  entry_no; 


/*  Load  the  initial  part  of  request 
while  (  not  the  end  of  the  record  ) 


begin 


end 


/*  Load  the  attribute  case  */ 
/*  Load  the  attribute  value  */ 


end 


/*  Load  the  end  of  request  */ 
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UESim  £ 

DBSIGH  SPECIFICATION  OF  THE  TEST  REQUEST  GEIERATIOH  PACKAGE 


The  program  specification  for  the  test  request  genera* 
tion  and  execution  package  is  shewn  in  this  appendix.  This 
design  is  the  result  of  the  work  of  Or.  Kerr,  who  headed  the 
design  of  the  original  test  request  generation  package. 

Tfre  Top  Level  c£  Test  Request  Generation  Package 

This  prograa  can  be  used  tc  test  and  deaonstrate  MDBS. 
The  execution  of  this  prograa  is  called  a  session.  Each 
session  can  be  divided  into  any  number  of  subsessions. 
During  a  subsession  the  user  can  do  one  of  the  following: 

(&)  Execute  a  list  of  requests  that  was  previously 
stored  in  a  file. 

(B)  Prompt  the  user  for  a  list  of  requests  to  be 
stored  in  a  file  for  later  use. 

(C)  Retrieve  a  list  cf  re  guests  that  were  previ¬ 
ously  stored  in  a  file  and  then  allow  the  user  to 
select  requests  free  that  list  for  execution. 
This  selection  can  be  done  in  any  order.  The  user 
will  also  be  able  to  enter  a  new  request  to  be 
executed. 

(D)  Hodify  an  existing  list  of  requests  that  was 
previously  stored  in  a  file. 

In  this  version*  requests  are  allowed  to  be  grouped  as 
transactions.  A  reguest  is  sent  to  HOBS.  The  prograa  waits 
for  a  response  before  sending  the  next  request  or  will 
continue  to  execute  without  response  if  the  user  so  desires. 

Output  may  be  directed  to  the  user's  terminal  or  to  a 
file  or  tc  both. 


ttaaElfl.  Specifications 


task 

scalar 


/****«**** ******* ***/ 
/♦  */ 

/*  Test  Bequest  */ 
/*  Generation  */ 

/*  Package  Design  */ 

/*  */ 

/****«**************/ 

HDES  Test* 

aore-sufcsessioas ;  /*  flag:  T BUS  - 

FILSE  - 


continue, 
stop  */ 


Print  initial  aessage  to  user; 
aore- subsessions  : *  TBUE; 

while  aore-subsessions  do 
perfora  subsession; 

Proapt  for  continue  aessage; 

Bead  continue  aessage; 

if  user  dees  not  want  to  continue 
then 

aore-subsessions  :=  FALSE; 

end  if 

end  while  ; 
end  task  ; 


procedure  SUBSESSION; 

/*  During  a  subsession  the  user  is  able 

/*  to  generate  a  group  of  requests.  (NEW  LIST) 

/*  to  aodify  an  old  list  of  requests.  (MODIFY) 

/*  to  select  requests,  one  at  a  time  from  a  lis* 

/*  of  requests.  (SELECT) 

/*  to  run  a  group  of  requests.  (OLD  LIST) 


I 


scalar 


cu 


scalar 


/.  -  - 


The  naae  of  the  file  */ 
value'should ’ be  NULL.  This  na£e  mult  be 
retained  from  one  subsession  to  the  next. 


tvpe-of-subsession:  /*  Possible  values  are  NEW  LIST, 
MODlfY,  SELECT  and  OID _ LIST  */  ~ 

Prompt  for  next  type-o  f- sub  session; 

Head  next  type-of-subsession  ; 

case  tvpe-of-subsession  value 

NEW _ LIST:  /*  Enter  a  new  request-list  */ 

perfora,,  NEW _ LIST _ SuBf  current-raquest-f ile)  ; 

MODIFY:  /♦  Modify  aff  old  Ust  */ 

perfora  MODIFY  SUB(  current-request-file  ); 

SELECT:  /*  Select  requ55ts.  one  at  a  time,  froa  an  */ 

/*  existing  request-list  */ 
perfora  SELECT  SUB(  current-request-file  )  ; 

OLD _ LxST:  /*  Execute  SIT  existing  request-list  */ 

perfora  OLD _ LIST _ SUB(  current-request-file)  ; 

otherwise  :  Prinf  erref^message ; 
end  case  ; 
end  procedure  ; 


procedure  NEW  LIST  SUB (  output  :  current-regues 
scalar  cuIYent-T5guest-f ile;  /*  naae  of  the  file 


/*  Asks  us) 


fo: 


i  user 

/*  Saves  list  o 
/*  user. 


requests  -  cne  at  a 
requests  in  a  file 


est-file  )  ; 

'  -  */ 

time.  */ 

with  file-naae  given  by  */ 

*/ 


scalar 

record 

scalar 


tc  use  to  store  the  requests  */ 

request; 

next-step; 
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/*  X(nsert),  Retrieve),  U(pdate),  D(elate)  or  P(inish)  */ 


Prompt  for  re 
Read  reguest- 


Read 

Open 


or  reggest-list-file-naae; 
reguest-list-f  ile- naae ; 
file(  reguest-list-file-name 
ENTER  AND  SAVE  REQUEST 


perform,  ENTEH  AND _ SAVE _ REQUESTS  ( 

Close  file(  request ^Tist-nls-nane  ); 
current-request-file  :*  request-lis t- 


-naae  )  output; 

SQUESTS  (  request-list-f ile-na me  ); 


tt-request 

procedure 


•f  ile-naee; 


procedure  MODIFT  SUB  (  input/cutput  :  current-reguest-fi  le  ); 
scalar  curr?nt-reguest-f  ile;  /*  The  naae  of  tae  file  */ 

/*  Retrieve  an  cld  reguest-list  a&d  then  allow  the  us?r  to  */ 
/*  modify  it.  Requests  are  examined  one  at  a  time  allowing  */ 
/*  changes  to  fce  made  to  each  request  in  turn.  A  change  */ 


/*  changes  to  fce  made  to  each  request  in  turn.  A  change 
/*  can  ce 

/*  add  new  request  before  this  one. 

/*  modify  this  request. 

/*  remove  this  request. 

/*  make  no  changes  to  this  request. 

/*  Note  that  we  must  have  a  way  to  append  new  requests  at 
/♦  the  end  of  the  input  request  list. 

/♦  The  input  file  (  called  input-request-file  )  may  be 
/*  either  the  current-reguest-file  or  a  different  existing 
/*  request  file. 

/*  The  output  file  (  called  new-request-file  )  may  be 
/*  either  the  next  version  of  the  mput-request-file  or  a 
/*  new  file. 


% 

I 


scalar  input-reguest-file;  /*  The  list  of  requests 

to  be  modified.  */ 

scalar  new-request-file;  /*  The  new  list  of  requests.  */ 
scalar  next-versicn;  /*  flag:TRUE-set  new-request-file  to  */ 
/♦next  version  of  input-request-file,  FALSB-get  new  name*/ 
record  request; 

scalar  more-requests-in-input-reguest-file:/*continue  flag*/ 
scalar  mere- regaests-to- enter;  /*  continuation  flag  */ 
scalar  change-type;  /*  ADD,  HODIPT,  REMOVE,  or  nochange  */ 

scalar  next-step;  ,  ,  . 

/*  I(nsert)  ,  R(etrieve),  U(pdate),  D(elet9)  or  P(inish)  */ 

/*  Determine  input-request-file  to  be  modified.  */ 

perform  DETERMINE  INPUT _ FILEj[  current-request-f lie, 

input-request-file  )  ; 
open  file(  input-request-file  )  input; 


/♦Determine  if  user  wants  the  same 
/*  to  be  the  next  version  of  the  i 


of  the  new-r< 
npu  t-request-2 


/«  to  be  the  next  version  of  the  inpu t-request-fi 
/♦  or  a  new  name.*/ 

Prompt  user  to  determine  next-versicn; 

Read  next-version ; 
if  next-version 
then 

Set  new-request-file  tc  next  version  of 
input-reguest-f  ile; 

e  lse 

Prompt  for  new-request-file  name; 

Read  naae  of  new-request-file; 
end  .  if  ; 

open  file(  new-request-file  )  output; 

Read  first  request  from  input-reguest- file: 
more- requests-in-input-request-f lie  :■  TRUE; 
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while  aore-reguests-in-input-re 
Proapt  user  for  change-type  for 
Bead  change-type: 

case  change-type  value 
ADD:  /*  enter  and  save  the 
perfora  SE?  NEW  B 
Write  reguest  intc  n35- 
MODIFY: 

Proapt  and  get  aodified 
Write  new  reguest  into 
Bead  next  request  from 
BEHOVE: 

Bead  next  request  from 
NO  CHANGE: 

”  Write  current  reguest  i 
Bead  next  request  from 
otherwise  :  Print  systea 
end  case  ; 
end  while  ; 


s  request; 


next  request  */ 

EQUIST (  request  ); 
request-file ; 

reguest  from  user; 
new -re  quest- file : 
input -reguest-f ile; 

input-request-file; 

nto  nev-request-file; 
input-request-file ; 
error  message; 


/*  Note  that  at  this  point  all  the  cld  requests  have  been  */ 
/*  processed.  However  it  is  possible  that  the  user  wants  */ 
/*  to  append  aore  requests.  */ 

Proapt  user  that  input  file  has  bees  processed,  but  that 
aore  requests  may  still  be  appended; 
perform  ENTER  AND  SAVE  BEQUE  STS  (new-request-file)  ; 
close  f|le(  input-f equ?3t-f iT3  )  ; 
close  file(  new-request-file  ); 
current-request-file  :  =  new-request-file; 
end  procedure  ; 


procedure 
sea  la  r 


SELECT  SUB(input/cutput  :  current-r 
currenT-reguest-f ile;  /*  The  name  of 


/*  Retrieve  an  old  list  of  requests. 
/*  Allow  user  to  select  from  this  li 
/*  Also  all 


er  to  select  from  this  list, 
ov  user  to  enter  new  request. 


request -me  i 

the  file  */ 

*/ 

V, 


scalar 

array 


input-request-file:  /*  file  containing  requests*/ 

requests]  MAX  NUMBER  CF _ BEQUESTS  ); 

/*  frca”laput-r3^ue3T-f ile  */ 
scalar  number-of-reguests:  /*  The  actual  number  in  */ 
/*  input-reguest-fila  must  be  less  than  */ 

/*  MAX  NUMBER  CF  BEQUESTS  */ 

scalar  Teguestr  number;  /*  of  the  request  chosen  */ 
record  new-request:  /*  Provided  by  user.  */ 

record  response;  /*  to  the  request  being  executed.  */ 


scalar  aore- to- ex scute;  /*  flag  to  control  loop  */ 

scalar  next-operation: 

/*  Values  can  be  REQUEST  NUMBER,  DISPLAY,*/ 

/*  NEW _ BEQUEST  or  STOP  —  */ 

/*  Deteraine  the  new  input-request- file  to  use  for  */ 

/*  this  subsession.  */ 

perform  DETERMINE  INPUT  FILE (  current-request-f ile, 

input-regbest-r  ile  )  ; 
open(  input-request-file  ) ; 

Bead  and  store  input-request-file  into  requests  checking  that 

nuaber-of-reguests  is  less  than  MAX _ NUMBER  OF  BEQUESTS; 

close  (  input-request-file  ) ; 
perfora  DISPLAY (  requests  ); 

/♦Determine  whet h|r^ response  is  to  go  to  CBT,  file  or  both*/ 
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■ore- to -execute  :■  THUS ; 

while  more-to-execut e  do 

Prompt  user  for  next -ope  rati  on  /*should  be  either*/ 

/*  reguest-number,  a  request -to-display  or  a  */ 

/*  new-request  */ 

Bead  next-operation; 

case  next-operation  value 
REQUEST  NUHBER: 

CheTK  that  request-number  is  lass  than 
number -o  f  -re  quests; 

perform  EXECUTE  (  re  quests  (raquest-numbert  , 
response  ) ; 

/*  Output  the  response  to  CRT,  file  or  CRT  Sfile 
as  appropriate.  */ 
perform  cuTmIeespon SE (  response  )  ; 

DISPLAY:  perform  display(  requests  ); 

BBS  BEQUEST: 

perform  GET  NEW  BEQUEST (  new-request  ); 
perform  3XECTJTE  (“new-request,  response  ); 

/*  Output  the  response  to  CRT,  file  or  CRT  Sfile, 

as  appropriate.  */  “ 

perform  OUTM$SESPONSS  (  response  ); 


end 


STOP:  more-to-execute  :=  FALSE; 
otherwise  :  print  error  message; 
end  case  ; 
while  ; 


perform  outmJfinisH: 
current-request-file  :=  input-reguest-file; 

end  procedure  ; 


procedure 
sea  la  r 


OLD _ LIST _ SOB (  current-reguest-file  ); 

curEent -request -file;  /*  The  name  of  the  file  */ 


/*  Retrieve  and  execute  an  old  list  of  requests.  */ 

scalar  input-request-file  /*  The  file  containing  requests*/ 
record  request; 

record  response;  /*  to  a  request  that  has  been  executed.  */ 


Determine  the  new  cur  rent -request-file  to  use  for  this*/ 
subsession.  */ 

erform  DETERHINE  input  FILE (  current-reqvest-f ile. 


'A  - 

perform 


ut-reqT5est-£ile  ) 
e.)  input; 


ad  first  request  from  input-request-file; 


/*  Determine  whether  response  is  to  go  to  CRT,  file  or  both, 
perform  OUTBJPOBHAT ; 
while  more-requests  do 

perform  EXECUTE (  request,  response  )  ; 

/*  Output  the  response  to  CRT,  file  or  CRT  Sfile,  as  */ 
/*  appropriate.  */ 

perform  CUTHjResponse  (  response  ): 

Read  next  request  from  input-re  quest-file ; 
end  while  ; 


perform  OUTHIFINISH: 
close (  input-request-file  )  ; 
current-request- file  : *  input- 


reques 


put-re  quest- file; 


end  procedure  ; 


V 
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procedure  BHTER__AHE_SAVE _ BEQUESTS 

(  input  :  reguest-list-fila- name  ); 
scalar  request-list  -file-name; 

/*  of  file  tc  use  to  store  the  requests  */ 
record  request; 
scalar  next-step; 

/*  I(nsert),  R(etrieve),  U(pdate),  D  (elete)  or  P  (inish)  */ 


end 


next-step  ;»  I; 

while  next- step  °«  F  do 
Prospt  for  next-step; 

case  next-step  value 

I:  /*  enter  and  save  the  next  insert  request  */ 
perform  INSERT  SUE(  request  )  ; 

Write  requeft  into  r equest-list-f ile-naae  ; 
R;  /*enter  and  save  next  retrieve  request  */ 
perfora  RETRIEVE  SDB(  request  ); 

Write  request  into  rf^uest-list- file-name  ; 
0;  /*  enter  and  save  the  next  update  request  */ 
perfora  DELETE  SUB(  request  \ ; 

Write  request  intoTequest-Iist-f lie-name  ; 
D;  /*  enter  and  save  the  next  delete  request  */ 

Eerfbra  DEIETE SUB(  request  ): 

te  request  into  request-list-file-name  ; 
P:  /*  Finish  entering  requests  V 

otherwise  :  Print  error  message; 
end  case  ; 
while  ; 


end 
procedure 


procedure  DETER fll RE I  SPOT FILE(  input  : 

currert-re guest- f ile , 
output  :  fnput-request-f ile  )  ; 
cur  r  ent- r  e  que  st- f  i  le ; 
inp  u  t  -re  quest  -file; 


scalar 

scalar 


/*  Determine  the  incut  fjll 
/*  the  current-request-fil 
/*  request  file. 


e  tc  be 
e  or  a 


aif 


ed.  It  either*/' 


ferent  ex: 


.ng 


V, 


scalar 


■odify-curr  ent-f ile -flag ; 

true  -  select  new  input  file  */ 


if 


end 

end  if  ; 
end  procedure 


current-request-f  ile  is  HULL 
then 

Prompt  fcr  name  of  input-reguest-file; 

Bead  naii.  of  input-request-file: 
else  /*  Determine  if  user  wants  to  use  the  */ 

/*  current-re  guest- file  or  a  different  old  file.  */ 
Prompt  user  to  determine  aodif y-current- file- flag ; 
Bead  eodify-curr ent-fil^-flag; 
if  mcdify-current-file-flag 
then 

Prompt  for  name  of  input-raguest-file; 

Bead  name  of  input- request-file ; 

else 

in^ut- reguest-file  :*  current-reguest-file; 


procedure 


GET  HEW  REQUEST  (  out 
recTSTd  Tequest;  /*  to 


put  :  request  )  ; 
be  obtained  from  user 


*/ 
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/♦  Prone ts  user  for  information  necessary  to  enter  a  */ 
/*  nev  request.  Returns  the  request.  */ 


request. 


scalar  request-type; 

/*  I(nsert) ,  R(etrieve),  D(pdate)  or  D (elate) 


Prompt  fcr  next  request-type; 
Bead  request-type; 

case  request-type  ▼ 

I:  perform  INSERT 

U:  perform  UPDATE 

D:  perform  DELETE 

B:  perform  RETRIE 

otherwise  :  Print 
end  case  ; 

procedure  ; 


type  value 

INSERT  SUB(  request 

re  r\n  «  an  »!'■  ■  m  nn  I _  _ 


_ SUB(  request  )  ; 

0PDATEI2S0B(  request  f  i 

DELETE _ SUB  ?  request  )  ; 

RETRIEVE  S0B(  request  ); 
Print  erfSr  message; 


procedure  DISPLA7(  input  :  requests  ); 

/*  Display  the  requests  and  their  numbers  at  the  */ 
/*  terminal.  */ 

array  requests  (  MAX  BOMBER _ OP  REQUESTS  ); 

1  /*  to  b?“displa7^d."^/ 

end  procedure  ; 


procedure  EXECUTE  (  input  :  request, 

output  :  response  ) ; 

/♦  Ask  MDBS  to  execute  this  request.  Return  the  response.  */ 
record  request;  /*  to  be  executed  */ 

record  response;  /*  to  the  execution  of  the  request  */ 
end  procedure  ; 


LIST  OF  BBFBRSBC ZS 


Postgraduate  School 


Report  NPS52-83-006,  The 


and  capacity 
lenonTjaisn 


Postgraduate  School  Report  NPS52-83-007 , 

_ a  I _ 1  _  — *  _  .  l  •  4  1 _ _  1_ _ 4  n  .  1  _  « _ _  _  , 


The 
ys€em 
'rslqn 
Inti 


Naval  Postgraduate  School  Report  NPS52- 83-008,  The 

^lgaentaticn  ^cf  a _ Wulti-ba ckeud  Database  System 

jf?3 

0r5<  „ 

1983: 


Naval  Postgraduate  School 


Report  NPS52-82-008,  The 


Hl”lf£fo,  mfP^Blgias'S.','  Orooji, 

Shi,  Zong-Zhi,  and  Stravser,  Paula,  June,  1982. 


igui 

III, 


Naval  Postgraduate  School  Report  NPS52-83-003,  The 
I apleaa ntation  of  a  Multi-ba  ckend  Database  System 

jIMtncP11  StroP“  Midfept&r— - J  - 


t55“7i 

m.=M 


:sion  witl 

EMIII 


gingm  MnfMSfH,  “H5y  BoYffrr“xr<lxST3 - B77 

oeaurl jian,  Stevea  X..  Hsiao.  Davxd  R.,  K9rr,  Douglas 
S.,  ana  Orooji,  Ali,  March,  198  3. 


Bogdanowicz,  Robert,  Crocker, Michael,  Hsiao,  David  K. , 
Ryaer^Curtis,  j  Stone,  ^  Vincent,  and  Strawser,_  Paula, 


urtis,  stone,  Vincent,  ana  strawser,  Paula, 
mts  in  Benchmarking  Relational  Database 

,H.S7  TTfe3I37  XXva  1  ~P3XTfrsff  ate“S5-55Sr7 

',  California,  June,  1983. 


Stone,  Vincent  C.,  Design  of  Relational  Database 
Benchaarks.  S.S.  Thesis,  Xaval  Postgrf  cluate  5chooI7 
Toraia,  June,  198  3. 


Sore,  Marvin  and  Stube,  John,  Elements  of  System 
Analysis.  Ha.  C.  Broun  Publishing,  TsBXT  ~ 


Ham 
10 1» 

MU 


BIBLIOGBAPHY 


Hancock,  les  and  Krieger,  Morris,  The  C  Primer,  McGraw-Hill 
Book  Company,  N.Y.,  1583.  - * - 

Kernnigan,  Brian  and  Ritchie,  Dennis  M. ,  The  C  Programming 
Language.  Prentice-Hall,  1978. 


Digita  1 


BSjC-1  Ig^rfl-rgXtOS  gxecutiyg  Reference  Manual. 
Digital  Eg^i^Bent  Corp6tfati5!Tr  naynird,  BafeS. , 

^  Servi^s  ^  Ref  srenca  Manual, 
Digital  EguiplSnt  CSE?g?Sti5T5,  fcAylSrd,  TIT32., 


AA-H265 A-TC, 

1979. 

AA-DO 18B-TE  , 

1980. 


INITIAL  0  XSTHIEOTION  LIST 


Defense  Technical  Inforaatics  Center 
Caaeron  Station 
Alexandria,  Virginia  22314 

Dudley  Knox  Library,  Code  0142 
Naval  Postgraduate  School 
Honterey,  California  9394  3 


Departaent  Chair aan,  Code  52 
Departaent  cf  Computer  Science 
Naval  Postgraduate  School 
Honterey,  California  93943 


LT  Joseph  6.  Kovalchik 
113  Hcosevelt  Street 
Edvardsville,  Pennsylvania 


18704 


Office  of  Research  Administration 
Code  0 12A 

Naval  Postgraduate  School 
Honterey,  California  9394  3 


Computer  Technologies  Curricular  Office 
Code  37 

Naval  Postgraduate  School 
Honterey,  California  9394  3 


No.  Copies 
2 


2 


1 


2 


1 


1 


